There are many applications which require accurate time synchronisation between nodes in order to operate property, for example mobile technologies such as Wideband Code Division Multiple Access (WCDMA) and Long Term Evolution (LTE). Another example is the Common Public Radio Interface (CPRI) which is used to transport traffic between a Radio Equipment Controller (REC) and Radio Equipment (RE).
It is possible to provide time synchronisation between a pair of network nodes using a timing protocol such as the Network Time Protocol (NTP), defined by IETF RFC 5905 or the Packet Time Protocol (PTP), defined in IEEE 1588.
A master node, which has access to an accurate time source such as a Global Positioning System (GPS), provides a timestamp which, in the case of time synchronisation, is used to measure the roundtrip delay between the master node and a slave node. Based on the assumption that the path delay in the forward direction (from the master node to the slave node) is the same as the path delay in the reverse direction (from the slave node to the master node), the protocol calculates the path delay between the master node and slave node as half the round trip delay. Knowledge of this path delay may then be used to synchronise a clock at the slave node with a master clock at the master node, based on a synchronisation or timing reference received by the slave node from the master node. A similar method for determining path delay, and synchronising nodes, is provided by CPRI specifications.
However, the underlying network infrastructure may mean that the path or propagation delay in the forward direction between a pair of nodes is different from the path or propagation delay in the reverse direction between the pair of nodes. For example, traffic in the forward direction may travel through a different optical fibre from traffic in the reverse direction, or if the traffic in the forward and reverse directions travels through the same optical fibre, the traffic may for example travel on respective wavelength channels and thereby experience different transmission, or processing, characteristics. This difference in path delay is referred to as a path delay asymmetry.
The PTP protocol provides that, if path delay asymmetry between nodes is known, a correction may be made at the slave node to compensate for the path delay asymmetry. Calculating path delay asymmetry is however often extremely costly and time consuming. Path delay asymmetries may be calculated prior to start-up of a network.
However, a significant problem in the deployment of the PTP protocol (and of other protocols that are dependent on symmetric paths, such as CPRI) is that path delay asymmetries may change after start-up of a network, over a length of time such that the changes cannot be filtered out by local clocks at the slave nodes. These asymmetries are sometimes referred to as “Pseudo-constant” asymmetries. These path delay asymmetries may change, for example, due to a network resource failure which results in traffic being routed onto a protection path, or a network resource upgrade or repair. For example, in a network using wavelength-division-multiplexing (WDM), if the lambda scheme is changed, or the dispersion compensation mechanisms are updated, this may result in hundreds of nanoseconds up to several microseconds of additional path delay asymmetry.